Feat: Adding limit field to template and Taks, overriding the CLI args from task. #2420
Conversation
- Added limits fields to the template form and runs task dialog - Created DB fields for this new field to be stored - Changed Models to support parsing from database or api json - Overriding implemented of the limit from task to template to enable pre-run changes to take effect - Added language element for "limit" - Fixed a JS error that was getting thrown due to item elements was being tried to set while item was undefined - Made run dialog to display the args defined on template to make it obvious for the end-user to see what's going to be ran - Made it also override the args by the task to template, so that if you change the args on pre-run it's really a override.
- I previously made it to run by overriding template CLI args no matter what - This might cause the problem because there might be run with task dialog with integration which means it will override all template args to null - I implemented a helper function to detect if task args are exists and they are actually overridig the template cli args - Then I just replace template CLI with task override and just use template args there.
|
Not sure why codacy fails though... |
|
Thank you! Reviewing |
|
Thanks waiting for the response, we are kind of waiting this for migration. |
| }{ | ||
| { | ||
| tmplArg: "--ssh-extra-args=\"-p 3222\"", | ||
| taskArg: "--ssh-extra-args \"-p 3222\"", |
There was a problem hiding this comment.
Single argument can not contain space which separates key and value. It must be 2 separate arguments. Otherwise ansible-playbook doesn't accept this argument (tested).
There was a problem hiding this comment.
I didn't get full what you mean? Do you mean that --ssh-extra-args will only work if separator is = sign? Like: -ssh-extra-args="-p 3222"? and won't work with --ssh-extra-args "-p 3222"? If that's the case, how do you prevent this on template CLI args declaration already? And this is not a user mistake if that's the case? On the other hand this piece of code only is to determine if they are passing same argument from task CLI args, so that it can be overriden, I don't really touch CLI args how they look like, regex is just checking either first = or first white space and splits it from there, so it can compare the passed option, --ssh-extra-args in this case.
There was a problem hiding this comment.
@Gnyblast yes, it is true. Argument --ssh-extra-args "-p 3222" doesn't work in Semaphore.
You can try to call ansible CLI with params ansible-playbook '--ssh-extra-args "-p 3222"' and you will got error. But following command will work: ansible-playbook '--ssh-extra-args' '-p 3222'
Semaphore runs ansible by command like exec.Command("ansible-playbook", []string{"--ssh-extra-args \"-p 3222\""}) so it will not work. But following code will work: exec.Command("ansible-playbook", []string{"--ssh-extra-args", "-p 3222"})
There was a problem hiding this comment.
as I said before this piece of code here is just to test if the parser regex can split argument and it's value correctly by delimiter which is either = sign or a space. I don't do any formatting as you can see in the code below:
for _, taskArg := range taskExtraArgs {
for tai, tmplArg := range templateExtraArgs {
ok, err := isCLIArgsOverridden(tmplArg, taskArg)
if err != nil {
t.Log(err.Error())
}
if ok {
templateExtraArgs = append(templateExtraArgs[:tai], templateExtraArgs[tai+1:]...)
break
}
if slices.Contains(templateExtraArgs, taskArg) {
templateExtraArgs = append(templateExtraArgs[:tai], templateExtraArgs[tai+1:]...)
}
}
}
first piece with isCLIArgsOverridden is the logic split them by delimiter and decide if it's same argument key with different value, the:
1- if yes, that means it's an override and delete the one on templateExtraArgs since taskExtraArgs will override that specific arguments
2- If not and if there are duplicate, then again delete the on in templateExtraArgs since taskExtraArgs already have a duplicate of it.
So if user does a mistake on how to pass a CLI argument, which they can do it now with the current code, it's a user mistake and should be fixed by passing it correctly but using = sign or escaping correctly. Nothing changes there.
… for errCliOverrideParseError
When you override template args in new task dialog the isCLIArgsOverridden manages that well, but when you remove a CLI arg in new task dialog since it doesn't exist anymore the iteration doesn't know it and it falls back to template which it does exist there and then gets implemented, to solve this: - I added a new non-database field to front-end and backend called RemovedArguments - In the front-end I made a new data binding and when an template declarated argument gets deleted on task dialog it populates it to removed_arguments object - Then when this get sent to the back-end, then back-end first removes and RemovedArguments from templateExtraArgs, so this prevents falling back to template args and finding it again there - Then it does the rest same as before to compare and override if there are existing arguments both in template and task with same key but different values. - Also ArgsPicker was problematic on populating CLI args on task dialog especially for re-runs because it wasn't getting populated correctly when you were trying for few times, and also it wasn't population a "rerun" with whatever arguments was selected there before, so it would make it an actual re-run. - I also fixed a bug for re-run button on TaskList, word `Re` was getting declared twice as hardcoded prefixed to the word `run`. - Fixed the api-docs and ran the tests.
Fix for #1357 and making override of the CLI args from task run dialog: